Authenticating via mobile device

ABSTRACT

A first server device is configured to receive an authentication request from a second server device; add the authentication request to a queue associated with a user; and provide a representation of the queue to a mobile device of the user. The representation of the queue includes an entry for the authentication request. The first server device is further configured to receive, from the mobile device, authentication information, provided by the user, for the authentication request; determine that authentication, of the user, for the authentication request is successful based on the authentication information; generate an authentication response that indicates that the authentication, of the user, for the authentication request is successful; and transmit, by the first server device, the authentication response to the second server device.

BACKGROUND

A user uses a computer to access a web service (e.g., an online bankingportal) provided via a website. Before providing access to the webservice, the website often requires the user to use the computer toenter secret authentication information (e.g., a password). The websiteprovides the access to the web service after the computer transmits thesecret authentication information to a web server associated with thewebsite and the user is authenticated based on the secret authenticationinformation. The user is subjected to man-in-the-middle (MITM) attackswhen the secret authentication information is being transmitted from thecomputer to the web server. An MITM attack may include an attackerstealing (i.e., intercepting) the secret authentication information whenthe secret authentication information is transmitted.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an example environment in which systems and/ormethods described herein may be implemented;

FIG. 2 is a diagram of example components of a mobile device of FIG. 1;

FIG. 3 is a diagram of example components of one or more of the devicesof FIG. 1;

FIG. 4 is a diagram of example functional components of anauthentication server of FIG. 1;

FIG. 5 is a diagram of example components of an authentication requestof FIG. 3;

FIG. 6 is a flow chart of an example process for populating queues withauthentication requests;

FIG. 7 is a flow chart of an example process for authenticating via amobile device; and

FIG. 8 is a flow diagram of an example authentication of the mobiledevice.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings.The same reference numbers in different drawings may identify the sameor similar elements

An implementation, described herein, may provide authentication, for aweb service, via a mobile device. For example, a website may require auser to be authenticated before providing access to a web service of thewebsite. In one implementation, a user may use a computer terminal toprovide a non-secret unique identifier (e.g., a username, a telephonenumber, an email address, etc.) to a web server that hosts the website.The web server may transmit an authentication request, for the user, toan authentication server (e.g., of a cellular service providerassociated with the user). The authentication server may add theauthentication request to an end of a queue associated with the user.The authentication server may transmit, to one or more mobile devicesassociated with the user, notifications that the authentication requesthas been added to the queue.

The user may use a mobile device to access a client (e.g., a webinterface) used for accessing a list and/or any other representation ofpending authentication requests in the queue of the user. The user mayselect the authentication request. The authentication server may promptthe user to provide authentication information (e.g., a password, apersonal identification number (PIN), a one time passcode, an answer toa challenge question, biometrics information, etc.) required toauthenticate the user for the selected authentication request. The usermay use the mobile device to provide the authentication information. Theauthentication server may receive the authentication information, andauthenticate the user for the selected authentication request based onthe authentication information. Thereafter, the authentication servermay transmit an authentication response to the web server that indicatesthat the user was successfully authenticated for the authenticationrequest. In response to the authentication response, the web server mayallow the user to use the computer terminal to access the web service ofthe website. Because the user uses the mobile device to provide theauthentication information, the user is not subject to a MITM attack dueto the authentication information or any other secret information,associated with the user, being transmitted between computer terminal120 and web server 130.

FIG. 1 is a diagram of an example environment 100 in which a systemand/or method described herein may be implemented. As shown in FIG. 1,environment 100 may include one or more of the following components: amobile device 110, a computer terminal 120, a web server 130, anauthentication server 140, and a network 150. A single mobile device110, computer terminal 120, web server 130, authentication server 140,and network 150 have been illustrated in FIG. 1 for simplicity. Inpractice, there may be more mobile devices 110, computer terminals 120,web servers 130, authentication servers 140, and/or networks 150. Also,in some implementations, one or more of the components of environment100 may perform one or more functions described as being performed byanother one or more of the components of environment 100.

Furthermore, two or more of the components, of FIG. 1, may beimplemented within a single device, or a single component may beimplemented as multiple, distributed devices. Also, components ofenvironment 100 may interconnect via wired and/or wireless connections.In other words, any two components, of environment 100, may communicatevia a wired connection, a wireless connection, or a combination of awired connection and a wireless connection.

Mobile device 110 may include any computation or communication device,such as a communication device that is capable of communicating withauthentication server 140 via network 150. In one implementation, mobiledevice 110 may take the form of a smart phone, a personal digitalassistant (PDA), a mobile telephone device, a handheld computer, apersonal media player, etc. In another implementation, mobile device 110may take the form of any computer, including a web service terminal, apersonal computer, a laptop computer, or any other device capable oftransmitting and/or receiving data.

In one example, mobile device 110 may allow a user of mobile device 110to access a client to view pending authentication requests associatedwith the user. The user may use mobile device 110 to select one of theauthentication requests and to provide authentication informationrequired for the authentication request. Mobile device 110 may receivethe authentication information (e.g., a password, a PIN, a one timepasscode, an answer to a challenge question, biometrics information,etc.), and transmit the authentication information to authenticationserver 140.

Computer terminal 120 may include any computation or communicationdevice, such as a communication device that is capable of communicatingwith web server 130 via network 150. In one implementation, computerterminal 120 may take the form of any computer, including a web serviceterminal, a personal computer, a laptop, a handheld computer, a smartphone, a mobile telephone device, a personal media player, etc. Computerterminal 120 may be operated by a user of mobile device 110. Computerterminal 120 may allow the user to access a website associated with aweb service provided by web server 130. Computer terminal 120 mayreceive, from web server 130, and display a log-in webpage for accessingthe web service. Computer terminal 120 may receive input(s) from theuser, including a request to use wireless authentication and/or anon-secret unique identifier, of the user, in order to access the webservice. Computer terminal 120 may transmit the request to use wirelessauthentication and/or the non-secret unique identifier to web server130.

In another implementation, computer terminal 120 may be operated by athird party requiring a verification from the user (e.g., an enterpriserequiring the user's confirmation/permission and/or digital signature, aparty seeking to confirm the user's identity, etc.). In yet anotherimplementation, computer terminal 120 may be a part of web server 130 orbe directly connected to web server 130 through network 150, and beoperated by an operator of web server 130.

Web server 130 may include any computation or communication device, suchas a communication device that is capable of communicating with computerterminal 120 and/or authentication server 140 via network 150. Webserver 130 may represent a single server device or a collection ofmultiple server devices and/or computer systems. Web server 130 may hosta website. Web server 130 may handle a transaction (e.g., a request toaccess an online portal associated with an account of a user, an onlinepurchase, a request for verification of a person's identity, etc.)initiated at computer terminal 120, by a user of mobile device 110 whoaccesses the website by using computer terminal 120.

Web server 130 may transmit a log-in web page to computer terminal 120for the user to access the web service/initiate the transaction via thewebsite. Web server 130 may request authentication server 140 to invokemobile device 110, and request a wireless authentication, of the user,based on a non-secret unique identifier that is selected/entered via thelog-in web page. Web server 130 may generate and transmit anauthentication request to authentication server 140 to authenticate theuser before providing the access to the web service via the website. Webserver 130 may receive, from authentication server 140, an approval forthe transaction and an authentication response that indicates that theuser has been successfully authenticated.

Authentication server 140 may represent a single server device or acollection of multiple server devices and/or computer systems. In oneimplementation, authentication server 140 may receive authenticationrequests from web server 130 and/or one or more other web servers thatprovide different web services. Authentication server 140 may maintainqueues for different users, including a queue for a user of mobiledevice 110. Authentication server 140 may add each one of the receivedauthentication requests to one of the queues. Authentication server 140may transmit a notification to mobile device 110 to notify the user ofmobile device 110 when a new authentication request is added to thequeue associated with mobile device 110.

In one example, authentication server 140 may allow a user of mobiledevice 110 to use mobile device 110 to access a client to viewinformation about pending authentication requests in a queue associatedwith the user. Authentication server 140 may also allow an operator ofweb server 130 to access a different client to view information aboutauthentication requests, in one or more of the queues, which arereceived from web server 130 and/or one or more other web serversassociated with the operator.

Authentication server 140 may receive a selection to approve one of thepending authentication requests from mobile device 110. In oneimplementation, the selected authentication request may include rulesthat specify what authentication information needs to be provided by theuser for the user to accept/approve the selected authentication request.Mobile device 110 may collect the authentication information from theuser based on the rules. In another implementation, authenticationserver 140 may determine what authentication information is required inorder to authenticate the user for the selected authentication request.Authentication server 140 may transmit a message to mobile device 110for the user to provide the authentication information.

Authentication server 140 may receive the authentication information(e.g., with/in a request to accept/approve or reject the selectedauthentication request) from mobile device 110, and authenticate theuser based on the authentication information. Authentication server 140may transmit, to web server 130, an authentication response thatindicates that the user has been successfully authenticated for theselected authentication request.

Network 150 may include a single network, multiple networks of a sametype, or multiple networks of different types. For example, network 150may include one or more of a direct connection between devices, a localarea network (LAN), a wide area network (WAN) (e.g., the Internet), ametropolitan area network (MAN), a wireless network (e.g., a generalpacket radio service (GPRS) network), a telephone network (e.g., aPublic Switched Telephone Network (PSTN) or a cellular network), asubset of the Internet, an ad hoc network, a fiber optic network (e.g.,a fiber optic service (FiOS) network), or any combination of theaforementioned networks.

FIG. 2 is a diagram of example components of mobile device 110. As shownin FIG. 2, mobile device 110 may include a housing 200, a speaker 210, adisplay 220, control buttons 230, a keypad 240, a microphone 250, and/ora camera 260. Housing 200 may include a chassis on which some or all ofthe components of mobile device 110 are mechanically secured and/orcovered. Speaker 210 may include a component to receive input electricalsignals from mobile device 110 and transmit audio output signals, whichcommunicate audible information to a user of mobile device 110.

Display 220 may include a component to receive input electrical signalsand present a visual output in the form of text, images, videos and/orcombinations of text, images, and/or videos which communicate visualinformation to the user of mobile device 110. In one implementation,display 220 may display text input into mobile device 110, text, images,and/or video received from another device, and/or information regardingincoming or outgoing calls or text messages, emails, media, games, phonebooks, address books, the current time, etc.

Control buttons 230 may include one or more buttons that accept, asinput, mechanical pressure from the user (e.g., the user presses acontrol button or a combination of control buttons) and may sendelectrical signals to processing unit 320 that may cause mobile device110 to perform one or more operations. For example, control buttons 230may be used to cause mobile device 110 to transmit information. Keypad240 may include a standard telephone keypad, keyboard, or anotherarrangement of keys. In an alternative implementation, keypad 240 may bepresented as part of display 220.

Microphone 250 may include a component to receive audible informationfrom the user and send, as output, an electrical signal that may bestored by mobile device 110, transmitted to another user device, orcause the device to perform one or more operations. Camera 260 may beprovided on a front or back side of mobile device 110, and may include acomponent to receive, as input, analog optical signals and send, asoutput, a digital image or video that can be, for example, viewed on thedisplay 210, stored in the memory of mobile device 110, discarded and/ortransmitted to another mobile device 110.

Although FIG. 2 depicts example components of mobile device 110, inother implementations, mobile device 110 may contain fewer, additional,different, or differently arranged components than illustrated in FIG.2. In one example, mobile device 110 may also include one or morecomponents described below with reference to FIG. 3. In another example,mobile device 110 may also include one or more additional componentsused to receive biometric information, in addition to microphone 250 andcamera 260, including, for example, a fingerprint scanner, a laserscanner, etc. In still other implementations, one or more components ofmobile device 110 may perform one or more tasks described as beingperformed by one or more other components of mobile device 110.

FIG. 3 is a diagram of example components of a device 300 that may beassociated with mobile device 110, computer terminal 120, web server130, and/or authentication server 140. Each one of mobile device 110,computer terminal 120, web server 130, and authentication server 140 mayinclude one or more devices 300 and/or one or more of each one of thecomponents of device 300.

As shown in FIG. 3, device 300 may include a bus 310, a processor 320, amemory 330, an input component 340, an output component 350, and acommunication interface 360. In another implementation, device 300 mayinclude additional components, fewer components, different components,or differently arranged components than are shown in FIG. 3.

Bus 310 may include a path, or a collection of paths, that permitscommunication among the components of device 300. Processor 320 mayinclude a processor, microprocessor, or processing logic that mayinterpret and execute instructions. Memory 330 may include any type ofdynamic storage device that may store information and instructions forexecution by processor 320, and/or any type of non-volatile storagedevice that may store information for use by processor 320.

Input component 340 may include one or more input mechanisms that permita user to input information to device 300. Output component 350 mayinclude one or more output mechanisms that output information to theuser. Examples of input and output mechanisms may include buttons (e.g.,control buttons 230, keys of keypad 240 or a keyboard, a mouse, ajoystick, etc.); a touch screen interface to permit data and controlcommands to be input into device 300; a speaker (e.g., speaker 210) toreceive electrical signals and output audio signals; a microphone (e.g.,microphone 250) to receive audio signals and output electrical signals;a display (e.g., display 220) to output visual information (e.g., webpages, transaction information, mobile pin pad interface, etc.); avibrator to cause device 300 to vibrate; a camera (e.g., camera 260) toreceive video and/or images; etc.

Communication interface 360 may include any transceiver-like mechanismthat enables device 300 to communicate with other devices and/orsystems. For example, communication interface 360 may include anEthernet interface, an optical interface, a coaxial interface, awireless interface, or the like.

In another implementation, communication interface 360 may include, forexample, a transmitter that may convert baseband signals from processor320 to radio frequency (RF) signals and/or a receiver that may convertRF signals to baseband signals. Alternatively, communication interface360 may include a transceiver to perform functions of both a transmitterand a receiver of wireless communications (e.g., radio frequency,infrared, visual optics, etc.), wired communications (e.g., conductivewire, twisted pair cable, coaxial cable, transmission line, fiber opticcable, waveguide, etc.), or a combination of wireless and wiredcommunications. Communication interface 360 may connect to an antennaassembly (not shown in FIG. 3) for transmission and/or reception of theRF signals.

The antenna assembly may include one or more antennas to transmit and/orreceive RF signals over the air. The antenna assembly may, for example,receive RF signals from communication interface 360 and transmit themover the air, and receive RF signals over the air and provide them tocommunication interface 360. In one implementation, for example,communication interface 360 may communicate with network 150 and/ordevices connected to network 150.

As will be described in detail below, device 300 may perform certainoperations. Device 300 may perform these operations in response toprocessor 320 executing software instructions (e.g., computerprogram(s)) contained in a computer-readable medium, such as memory 330,a secondary storage device (e.g., hard disk, etc.) or other forms ofrandom access memory (RAM) or read only memory (ROM). Acomputer-readable medium may be defined as a non-transitory memorydevice. A memory device may include space within a single physicalmemory device or spread across multiple physical memory devices. Thesoftware instructions may be read into memory 330 from anothercomputer-readable medium or from another device. The softwareinstructions contained in memory 330 may cause processor 320 to performprocesses described herein. Alternatively, hardwired circuitry may beused in place of or in combination with software instructions toimplement processes described herein. Thus, implementations describedherein are not limited to any specific combination of hardware circuitryand software.

FIG. 4 is a diagram of example functional components of authenticationserver 140. As shown in FIG. 4, authentication server 140 may includequeues 410-1, 410-2, . . . , 410-M (where M≧1) (collectively referred toas “queues 410” and individually as “queue 410”). Each one of queues 410may correspond to a different user. For example, queue 410-1 maycorrespond to a first user of mobile device 110, queue 410-2 maycorrespond to a second user of a second mobile device (not shown in FIG.1), etc.

Queue 410 may represent one or more locations in a memory device. Queue410 may include, for example, a linked list, continuous blocks of memorylocations, an array, a list object, a queue class, and/or one or moreother types of data structure.

Queues 410 may store authentication requests 420-1, 420-2, 420-3, 420-4,420-5, and 420-6 (collectively referred to as “authentication requests420” and individually as “authentication request 420”). Sixauthentication requests 420 have been illustrated in FIG. 4 forsimplicity. In practice, there may be additional or fewer authenticationrequests in each one of queues 410.

In one implementation, authentication request 420 may represent anextensible markup language (XML) object/payload that includesinformation about authentication request 420, as described further belowwith reference to FIG. 5. In another implementation, authenticationrequest 420 may represent an object that is an instance of a class forauthentication requests of a queue. In yet another implementation,authentication request 420 may include one or more types of datastructures that store information associated with an authenticationrequest.

Authentication server 140 may receive authentication requests 420 fromweb server 130 and/or from one or more other web servers (not shown inFIG. 1). Authentication server 140 may receive authentication request420 from web server 130 when web server 130 requires an authenticationof (the identity of) a user of computer terminal 120 and the userrequested wireless authentication (e.g., via mobile device 110 of theuser).

Authentication server 140 may add a received authentication request 420to one of queues 410 (e.g., queue 410-1) corresponding to a user (e.g.,the user of mobile device 110) identified in the received authenticationrequest 420. For example, as shown in FIG. 4, queue 410-1 may includeauthentication requests 420-1, 420-2, and 420-3, which are fortransactions associated with the first user of mobile device 110. Queue410-2 may include authentication request 420-4, which is for atransaction associated with the second user of the second mobile device.Queue 410-M may include requests 420-5 and 420-6, which are fortransactions associated with a third user of a third mobile device (notshown in FIG. 1).

The user of mobile device 110 may use mobile device 110 (and/or anothertype of computing device) to access a customer client used for viewingpending authentication requests associated with the user. The customerclient may include, for example, a user interface used by the user tointeract (e.g., request to view the pending authentication requests,select one of the authentication requests, etc.) with the authenticationserver 140. In one implementation, the user may access the customerclient via a browser. In another implementation, the user may access thecustomer client via a dedicated application that includes the customerclient.

Authentication server 140 may identify which queue (e.g., queue 410-1)is associated with the user when, or before/after, the user accesses thecustomer client. Authentication server 140 may transmit informationabout the pending authentication requests (e.g., authentication requests420-1, 420-2, and 420-3) that are in the identified queue. In oneimplementation, the customer client may display a list of the pendingauthentication requests. The user may select a particular authenticationrequest (e.g., authentication requests 420-1) included in the list toview more information about the particular authentication request.

In some implementations, each one of authentication requests 420, inqueues 410, may have rules embedded that specify a level ofauthentication required (e.g., type of authentication information thatneeds to be provided by the user via mobile device 110) for a particularauthentication request (e.g., authentication requests 420-1). Asdescribed further below, mobile device 110 may collect (e.g., prompt theuser to provide) authentication information from the user, based on therules embedded in the particular authentication request, when the userselects the particular authentication request from the list of thepending authentication requests.

An operator of web server 130 may use a computer device (not shown inFIG. 1) to access an operator client used for viewing pendingauthentication requests that have been transmitted by web server 130and/or from other web servers associated with the operator. The operatorclient may include, for example, a user interface used by the operatorto interact with the authentication server 140. In one implementation,the operator may access the operator client via a browser. In anotherimplementation, the operator may access the operator client via adedicated application that includes the operator client.

Authentication server 140 may identify one or more authenticationrequests (e.g., authentication requests 420-3 and 420-6), in one or moreof queues 410, that were received from web server 130 and/or the otherweb servers when, or before/after, the operator accesses the operatorclient. Authentication server 140 may transmit information about theidentified authentication requests to the computer device of theoperator. In one implementation, the operator client may display a listof the identified authentication requests associated with the operator.The list may not include any authentication requests associated withother operators (e.g., companies). The operator may select a particularauthentication request (e.g., authentication requests 420-3) included inthe list to view more information about the particular authenticationrequest.

FIG. 5 is a diagram of example fields of authentication request 420. Asshown in FIG. 5, request 420 may include one or more of the followingfields: a requesting party field 510, a target party field 520, a typeof request field 530, a level of authentication required field 540,and/or an expiring time field 550. In another implementation, request420 may include additional fields, fewer fields, and/or different fieldsthan are shown in FIG. 5.

Requesting party field 510 may include a unique identifier of web server130 and/or of an operator of web server 130 that issued a request toauthenticate an identity of a user via authentication request 420. Forexample, requesting party field 510 may include a name of an entity(e.g., Example Bank), an address of a website associated with the entity(www.example.com), and/or any other combination of characters thatuniquely identifies web server 130, a grouping of web servers thatincludes web server 130, the entity, the website, and/or a web serviceprovided by the entity.

Target party field 520 may include a user unique identifier of a userwho needs to approve a transaction associated with authenticationrequest 420 and/or whose identity needs to be authenticated for webserver 130. In one implementation, the user unique identifier mayinclude a non-secret identifier (e.g., a username, a telephone number,an email address, etc.) that the user entered via a log-in webpage,provided by web server 130, to prompt a wireless authentication processassociated with the transaction and/or authentication request 420. Inanother implementation, the user unique identifier may include any otheridentifier (e.g., a unique character string) shared by web server 130and authentication server 140 for the user. Authentication server 140may store user information (e.g., a mobile telephone number of mobiledevice 110, an identifier of one of queues 410, values for secretcredentials and/or biometric information) associated with the user inassociation with the user unique identifier.

Type of request field 530 may include information that specifies a typeof a transaction associated with authentication request 420 and/or atype of action required by the user for the transaction (e.g., to complywith the authentication request). For example, type of request field 530may specify that the user needs to approve an attempt to access aparticular web service; review and approve a particular message; reviewand approve a particular charge against an account of the user; reviewand approve a business decision of an entity (e.g., a company)associated with the user; review and approve a request to digitally signa particular document (e.g., a prescription for controlled substances);etc.

Level of authentication required field 540 may include information thatspecifies which authentication information the user is required toprovide via mobile device 110 in order to be authenticated forauthentication request 420. In one implementation, level ofauthentication required field 540 may include a value that correspondsto a predefined level of authentication required. For example, when thevalue is equal to “1,” the user may need to enter a PIN using mobiledevice 110; when the value is equal to “2,” the user may need to enter aPIN and/or a password; when the value is equal to “3,” the user may needto enter a password and provide biometrics information associated withthe user (e.g., a retina scan, a voice signature, a facial signature, afingerprint, etc.); etc.

In another implementation, the level of authentication required field540 may specify the authentication information that needs to beprovided. For example, level of authentication required field 540 mayindicate that the user needs to, via mobile device 110, enter a PIN andsay a particular authentication phrase (e.g., “my name is Dan M. and Iapprove this request”) to provide voice biometric information. Inanother example, level of authentication required field 540 may indicatethat the user needs to, via mobile device 110, enter a password andprovide retina scan information, fingerprint scan information, and/orfacial recognition information.

Expiring time field 550 may indicate a particular time at whichauthentication request 420 expires. The user may not accept and/orprovide authentication for authentication request 420 afterauthentication request 420 expires. The particular time may be a periodof time (e.g., 24 hours, 5 minutes, etc.) after the user uses computerterminal 120 to request wireless authentication, after authenticationrequest 420 is transmitted from web server 130, after authenticationrequest 420 is received by authentication server 140, after anotification about authentication request 420 is transmitted fromauthentication server 140 to mobile device 110, etc.

In some implementations, authentication server 140 may removeauthentication request 420 from queue 410 when authentication request420 expires. Thereafter, authentication server 140 may notify web server130 and/or mobile device 110 that authentication request 420 hasexpired.

FIG. 6 is a flow chart of an example process 600 for populating queueswith authentication requests. In one implementation, authenticationserver 140 may perform process 600. In another implementation, a deviceor collection of devices separate from, or in combination with,authentication server 140 may perform some or all of process 600.

Prior to process 600, a user of mobile device 110 may initiate atransaction. In one example, the user may use a browser of computerterminal 120 to access a website associated with web server 130. In someimplementations, the browser may store a cookie that indicates that theuser uses wireless authentication while accessing web servicesassociated with the website. Accordingly, the website may display anicon that allows the user to request wireless authentication when theicon is selected. The website may also prompt the user to enter anon-secret identifier associated with the user (e.g., a telephonenumber, an email address, etc.). The user may use computer terminal 120to select the icon to request the wireless authentication and/or toenter the non-secret identifier in order to initiate or complete thetransaction (e.g., access an online portal provided by the website,complete a purchase, etc.). In other implementations, the cookie mayinclude the non-secret identifier of the user. When the user selects theicon to request the wireless authentication, computer terminal 120 mayretrieve the non-secret identifier from the cookie.

Web server 130 may receive, from computer terminal 120, the request forthe wireless authentication and the non-secret identifier. In responseto the request for the wireless authentication, web server 130 maydetermine that the user requested/needs to be authenticated via a mobiledevice associated with the user (e.g., mobile device 110). Accordingly,web server 130 may transmit an authentication request to authenticationserver 140 for authentication server 140 to conduct the wirelessauthentication.

In another example, a user of mobile device 110 may be a person whoseverification is required to approve a transaction (e.g, an executive whoneeds to give approval for a decision, a doctor who needs to verify adrug prescription for a patient, a parent who needs to providepermission, in a form of a digital signature, for his child, a personwho needs to verify her identity to use a credit card to pay online, afirst responder who needs to verify her identity when she arrives at anaccident scene, etc.). A third party may use computer terminal 120and/or web server 130 to request an approval for the transaction andauthentication of the user doing the approval. Web server 130 mayreceive a transaction request for the transaction and transmit anauthentication request, based on the transaction request, toauthentication server 140.

As shown in FIG. 6, process 600 may include receiving an authenticationrequest (block 610). For example, authentication server 140 may receivethe authentication request, via network 150, from web server 130. Theauthentication request may include a requester identifier associatedwith the website and/or web server 130, a user identifier associatedwith the user (e.g., the non-secret identifier), information about thetransaction (e.g., a type of the transaction and/or a type of actionrequired by the user for the transaction), a level of authenticationrequired, and/or a rule for, or a particular time, when theauthentication request expires. The rule may indicate, for example, thatthe authentication request expires within a particular period of time(e.g., 24 hours) after a time when the authentication request was issuedby web server 130 or received by authentication server 140. In oneimplementation, when the authentication request includes the rule, theauthentication request may also include the time when the authenticationrequest was issued. In another implementation, authentication server 140may track the time when the authentication request is received and/oruse some other type of counter to determine when the authenticationrequest expires based on the rule.

Process 600 may further include retrieving user information (block 620).For example, after receiving the authentication request from web server130, authentication server 140 may determine the user identifier that isincluded in the authentication request for the user. Authenticationserver 140 may store or have access to user information that is storedin association with the user identifier. Authentication server 140 mayretrieve the user information based on the user identifier. The userinformation may include a queue identifier of a queue that includesauthentication requests for the user and/or unique identifier(s) (e.g.,telephone numbers, device identifiers (IDs), etc.) of one or more mobiledevices (e.g., including mobile device 110) associated with the user.

Process 600 may also include adding the authentication request to aqueue of a user (block 630) and transmitting a notification to the user(block 640). For example, after retrieving the user information,authentication server 140 may add the received authentication request toan end of the queue identified by the queue identifier. After adding theauthentication request, authentication server 140 may generate anotification that indicates that a new authentication request wasreceived for the user and/or added to the queue of the user.Alternatively, or additionally, the notification may instruct the userto retrieve the authentication request from the queue. Authenticationserver 140 may transmit the notification to mobile device 110 and/or oneor more other mobile devices of the user, via network 150, by using theunique identifier(s) (e.g., the telephone numbers or the device IDs)included in the user information of the user. Mobile device 110 mayreceive the notification and display, based on the notification, amessage that indicates that the authentication request was receivedand/or added to the queue of the user. In response to the message, theuser may use mobile device 110 to access a customer client to viewinformation about the authentication request and/or to approve theauthentication request.

FIG. 7 is a flow chart of an example process 700 for authenticating viamobile device 110. In one implementation, authentication server 140 mayperform process 700. In another implementation, a device or collectionof devices separate from, or in combination with, authentication server140 may perform some or all of process 700.

As shown in FIG. 7, process 700 may include receiving an access requestto access a queue of a user (block 710) and providing a list of pendingauthentication requests in the queue (block 720). For example, a usermay use mobile device 110 to access a customer client via a browser or adedicated application. The customer client may prompt the user to usemobile device 110 to enter a non-secret user identifier (e.g., ausername) and a secret credential (e.g., a password). Mobile device 110may transmit, to authentication server 140, the non-secret useridentifier and the secret credential as part of an access request toaccess a queue of the user. Authentication server 140 may determine thatthe user is allowed to access a queue of the user when the non-secretuser identifier and the secret credential match information stored forthe user. After determining that the user is allowed to access thequeue, authentication server 140 may identify pending authenticationrequests in the queue. The authentication server 140 may provide a listof the pending authentication requests to the customer client that isopen/executing on mobile device 110. The list may include an entry foreach one of the pending authentication requests. The entry may include aportion of information included in the corresponding authenticationrequest.

Process 700 may further include receiving a selection of anauthentication request (block 730). For example, mobile device 110 mayreceive the list of the pending authentication requests fromauthentication server 140. Mobile device 110 may present the list in thecustomer client. The user may use mobile device 110 to select anauthentication request from the list by selecting an entry of the listthat corresponds to the authentication request. The selection of theentry may include approving a transaction associated with theauthentication request. Mobile device 110 may transmit a messageindicating the selection of the authentication request to authenticationserver 140. Authentication server may receive the selection of theauthentication request in the form of the message.

Process 700 may also include determining a level of authenticationrequired (block 740). For example, after receiving the selection of theauthentication request, authentication server 140 may determine a levelof authentication required for the authentication request. Theauthentication request may include information about the level ofauthentication required. The level of authentication required mayspecify what authentication information needs to be provided by theuser, via mobile device 110, in order to successfully authenticate theuser for the authentication request.

Process 700 may also include prompting the user to provide and receivingthe authentication information (block 750). For example, the level ofauthentication required may indicate that the user is required toprovide a password and an authentication phrase, as a voice biometric,or fingerprint scan information for the authentication request.Authentication server 140 may prompt the user to provide the requiredauthentication information by transmitting instructions to mobile device110 to request the user to provide the required authenticationinformation. Mobile device 110 may display messages to the user based onthe instructions. Mobile device 110 may receive the requiredauthentication information (e.g., the password and the authenticationphrase or the fingerprint scan information) via one or more inputmechanisms, including, for example, a microphone or a fingerprintscanner. Mobile device 110 may transmit the authentication informationto authentication server 140. Authentication server 140 may receive theauthentication information from mobile device 110.

In another implementation, process 700 may not include blocks 730-750.Alternatively, rules regarding the level of authentication required maybe embedded in each one of the authentication requests, included in thelist of the pending authentication requests. After the user selectsselect an authentication request from the list, mobile device 110 mayprompt the user to provide authentication information based on rulesembedded in the selected authentication request. Mobile device 110 maycollect the authentication information, and transmit a selection of theauthentication request, together with the authentication information, toauthentication server 140.

In yet another implementation, after receiving the authenticationinformation, authentication server 140 may determine that additionalauthentication information is required due to weak authentication.Authentication server 140 may determine weak authentication when, forexample, mobile device 110 is outside of a particular geographic areaand/or is more than a particular distance from computer terminal 120.Authentication server 140 may transmit a prompt to mobile device toreceive the additional authentication information, and may receive theadditional authentication information in response. For example, rules inthe selected authentication request may specify that only a password isrequired for authentication. After authentication server 140 receivesthe password entered by the user via mobile device 110, authenticationserver 140 may determine weak authentication and transmit a PIN promptto mobile device 110. Authentication server 140 may receive a PINentered by the user in response.

Returning to FIG. 7, process 700 may also include determining thatauthentication is successful (block 760). For example, in oneimplementation, authentication server 140 may store and/or have accessto user information that includes authentication values for the user.The authentication values may include a PIN value, a password value, onetime passcode, and/or one or more biometric values. In anotherimplementation, the authentication request may include authenticationvalues which the authentication information must match to authenticatethe user. Authentication server 140 may determine that an authenticationof the user, for the authentication request, is successful when theauthentication information, received from mobile device 110, matchescorresponding authentication values. Further to the example above,authentication server may determine that the authentication issuccessful when the password, included in the authenticationinformation, matches the password value and the authentication phraseprovided by the user matches an authentication phrase biometric value orthe fingerprint scan information matches a fingerprint biometric value.

Process 700 may also include generating and transmitting anauthentication response (block 770). For example, after determining thatthe authentication of the user is successful, authentication server 140may generate an authentication response. The authentication response mayinclude information to notify web server 130 that the user complied withthe authentication request and that the identity of the user wassuccessfully authenticated (e.g., as required by the level ofauthentication of the authentication request). Authentication server 140may transmit the authentication response to web server 130. In responseto the authentication response, web server 130 may determine that theuser is authenticated and/or that the transaction is approved. In oneexample, when appropriate, web server 130 may provide/grant user accessto a portal (e.g., a web page) that requires the authentication of theuser prior to granting the access. In another example, web server 130may approve a transaction requested/associated with the user for whichthe authentication of the user.

Process 700 may also include updating the queue (block 780). Forexample, after determining that the authentication is successful and/orafter transmitting the authentication response, authentication server140 may update the queue associated with the user. In oneimplementation, updating the queue may include indicating that theauthentication request is no longer pending and/or that theauthentication request has been successfully approved by the user. Inanother implementation, updating the queue may include removing theauthentication request from the queue.

In one implementation, described herein, web server 130 may require auser to provide authentication information before allowing the user toaccess a web service using computer terminal 120. The user may usewireless authentication to provide the authentication information viamobile device 110. As a result, the user is not subject to a MITM attackbecause neither the authentication information nor any other secretinformation, associated with the user, is transmitted between computerterminal 120 and web server 130.

FIG. 8 is a flow diagram 800 of an example authentication of the mobiledevice. For example, as shown in FIG. 8, computer terminal 120 maytransmit a wireless authentication request 810 to web server 140 when auser uses computer terminal 120 to access a website associated with webserver 130 and selects wireless authentication. Wireless authenticationrequest 810 may include a non-secret identifier associated with theuser. In response to wireless authentication request 810, web server 130may transmit an authentication request 815 to authentication server 140for authentication server 140 to conduct the wireless authentication ofthe user.

Authentication server 140 may add authentication request 815 to a queueassociated with the user, and may transmit a notification 820 to mobiledevice 110, of the user, to notify the user that authentication request815 was received and/or added to the queue. After receiving notification820, the user may use mobile device 110 to transmit an access request825, to access the queue associated with the user, to authenticationserver 140. In response to access request 825, authentication server 140may provide a list of pending authentication requests 830, including anentry for authentication request 815, to mobile device 110.

Mobile device 110 may transmit a selection of authentication request 835to authentication server 140 when the user uses mobile device 110 toselect the entry for authentication request 815. In one implementation,authentication server 140 may determine what authentication information845 is required for the wireless authentication, and may transmitinstructions 840, to prompt the user to provide authenticationinformation 845, to mobile device 110. Mobile device 110 may transmitauthentication information 845 to authentication server 140 when theuser uses mobile device 110 to enter/provide authentication information845.

In another implementation, each one of the authentication requestsincluded in list of pending authentication requests 830, including theentry for authentication request 815, may include rules that specifyinstructions 840. Mobile device 110 may collect authenticationinformation 845 based on the rules embedded in the transactionassociated with authentication request 815. Mobile device 110 maytransmit selection of authentication request 835, together withauthentication information 845, to authentication server 140.

Authentication server 140 may transmit authentication response 850 toweb server 130 after authentication server 140 authenticates theidentity of the user based on authentication information 845. Inresponse to authentication response 850, web server 130 may provide aweb page 855, for which the authentication was required to access, tocomputer terminal 120. The user may use computer terminal 120 to viewand/or interact with web page 855.

The foregoing description provides illustration and description, but isnot intended to be exhaustive or to limit the embodiments to the preciseform disclosed. Modifications and variations are possible in light ofthe above teachings or may be acquired from practice of the embodiments.

While series of blocks have been described with regard to FIGS. 6 and 7,the order of the blocks may be modified in other implementations.Further, non-dependent blocks may be performed in parallel.

It will be apparent that systems and methods, as described above, may beimplemented in many different forms of software, firmware, and hardwarein the implementations illustrated in the figures. The actual softwarecode or specialized control hardware used to implement these systems andmethods is not limiting of the implementations. Thus, the operation andbehavior of the systems and methods were described without reference tothe specific software code—it being understood that software and controlhardware can be designed to implement the systems and methods based onthe description herein.

Even though particular combinations of features are recited in theclaims and/or disclosed in the specification, these combinations are notintended to limit the disclosure of the possible implementations. Infact, many of these features may be combined in ways not specificallyrecited in the claims and/or disclosed in the specification. Althougheach dependent claim listed below may directly depend on only one otherclaim, the disclosure of the implementations includes each dependentclaim in combination with every other claim in the claim set.

No element, act, or instruction used in the present application shouldbe construed as critical or essential to the implementations unlessexplicitly described as such. Also, as used herein, the article “a” isintended to include one or more items. Where only one item is intended,the term “one” or similar language is used. Further, the phrase “basedon” is intended to mean “based, at least in part, on” unless explicitlystated otherwise.

What is claimed is:
 1. A method comprising: receiving, by a first serverdevice, an authentication request from a second server device; adding,by the first server device, the authentication request to a queue ofauthentication requests associated with a user; providing, by the firstserver device from the queue, a list of authentication requests that arepending for the user to a mobile device of the user, wherein the list ofauthentication requests includes the authentication request from thesecond server device; receiving, by the first server device from themobile device, a selection of the authentication request by the userfrom the list of authentication requests that are pending for the user;transmitting, to the mobile device, instructions to requestauthentication information from the user in response to receiving theselection of the authentication request, wherein transmittinginstructions to request the authentication information comprises:determining a level of authentication required for the authenticationresponse, wherein the level of authentication required specifies theauthentication information required to successfully authenticate theuser for the authentication request; and generating the instructionsbased on the level of authentication required; receiving, by the firstserver device and from the mobile device, the authenticationinformation, provided by the user, for the authentication requestselected from the list of authentication requests; determining, by thefirst server device that authentication, of the user, for the selectedauthentication request is successful based on the authenticationinformation; generating, by the first server device, an authenticationresponse that indicates that the authentication, of the user, for theselected authentication request is successful; and transmitting, by thefirst server device, the authentication response to the second serverdevice.
 2. The method of claim 1, wherein the second server device isassociated with a website that requires the authentication of the userbefore providing access to a web service associated with the website, orwherein the second server requires the authentication of the user beforeapproving a transaction performed by a third party that requiresverification by the user for transaction approval.
 3. The method ofclaim 1, further comprising: generating the authentication informationin response to the instructions.
 4. The method of claim 1, wherein onlynon-secret information of the user is exchanged between a the computerdevice and the second server device before the first server devicereceives the authentication request from the second server device. 5.The method of claim 1, wherein the authentication information comprisesone or more of: a pin, a password, a one time passcode, anauthentication phrase provided by the user, a facial signature, or afingerprint.
 6. The method of claim 1, further comprising: determining auser identifier, of the user, included in the authentication request,and retrieving user information of the user based on the useridentifier, wherein the user information comprises a queue identifier ofthe queue and a unique identifier associated with the mobile device. 7.The method of claim 1, wherein providing the list of authenticationrequests to the mobile device comprises: transmitting, to the mobiledevice, a notification about the authentication request, receiving, fromthe mobile device, a request to access the queue, and providing the listof authorization requests from the queue in response to the request toaccess the queue.
 8. The method of claim 7, wherein the request toaccess the queue comprises a user identifier and a secret credential,and wherein the list of authorization requests from the queue isprovided only when the user identifier and the secret credential matchinformation stored, by the first server device, for the user.
 9. Themethod of claim 1, wherein determining that the authentication for theselected authentication request is successful comprises: retrievingauthentication values, of the user, from user information stored by thefirst server, or from the selected authentication request, anddetermining that the authentication for the selected authenticationrequest is successful when the authentication information matchescorresponding values of the authentication values.
 10. The method ofclaim 1, wherein the list of authentication requests comprises aplurality of authentication requests that are pending for the user. 11.The method of claim 1, wherein each of the plurality of authenticationrequests includes first data identifying a party requestingauthentication of the user via a respective one of the plurality ofauthentication requests, second data identifying the user that needs toauthenticate the respective one of the plurality of authenticationrequests, and third data that specifies a type of a transactionassociated with the respective one of the plurality of authenticationrequests or a type of action required by the user for the transactionassociated with the respective one of the plurality of authenticationrequests.
 12. The method of claim 11, wherein each of the plurality ofauthentication requests includes fourth data that specifies whichauthentication information that the user is required to provide via themobile device in order to be authenticated for a respective one of theplurality of authentication requests.
 13. The method of claim 11,wherein each of the plurality of authentication requests includes fourthdata that indicates a particular time at which a respective one of theplurality of authentication requests expires.
 14. A device comprising: amemory configured to store a queue associated with a user, wherein thequeue stores a list comprising a plurality of authentication requests;and a processor configured to: receive an authentication request from aweb server associated with a website accessed by the user, add theauthentication request to the list stored in the queue, as one of theplurality of authentication requests, receive an access request toaccess the queue from a mobile device of the user, provide, to themobile device, the list comprising the plurality of authenticationrequests in response to the access request, wherein the list includes anentry for the authentication request, receive a selection of theauthentication request from the list comprising the plurality ofauthentication requests, prompt the user to provide authenticationinformation for the selected authentication request, wherein, whenprompting the user to provide the authentication information, theprocessor is further configured to: determine a level of authenticationrequired for the selected authentication request, where the level ofauthentication required specifies the authentication informationrequired to successfully authenticate the user for the selectedauthentication request, determine instructions based on the level ofauthentication required, and transmit, to the mobile device,instructions to request the authentication information from the user,and receive the authentication information from the mobile device. 15.The device of claim 14 wherein the processor is further configured to:determine the authentication for the user is successful when theauthentication information matches authentication values stored for theuser or included in the selected authentication request, generate anauthentication response that indicates that the authentication, of theuser, for the selected authentication request is successful, andtransmit the authentication response to the web server associated withthe selected authentication request.
 16. The device of claim 15, wherein, after transmitting the authentication response, the processor isfurther configured to: remove the selected authentication request fromthe queue, or indicate, in the queue, that the selected authenticationrequest is approved by the user.
 17. The device of claim 14 wherein eachof the plurality of authentication requests includes: first dataidentifying a party requesting authentication of the user via arespective one of the plurality of authentication requests, second dataidentifying the user that needs to authenticate the respective one ofthe plurality of authentication requests, and third data that specifiesa type of a transaction associated with the respective one of theplurality of authentication requests, or a type of action required bythe user for the transaction associated with the respective one of theplurality of authentication requests, fourth data that specifies whichauthentication information that the user is required to provide via themobile device in order to be authenticated for a respective one of theplurality of authentication requests, and fifth data that indicates aparticular time at which a respective one of the plurality ofauthentication requests expires.
 18. One or more non-transitorycomputer-readable media storing instructions executable by one or moreprocessors of a device to perform a method, the method comprising:receiving an authentication request, associated with a user, from aserver, wherein the authentication request involves an interactionbetween a computer terminal and the server; adding the authenticationrequest to a queue of authentication requests associated with the user,wherein the queue includes a plurality of authentication requests thatare pending for the user; retrieving, from the queue, a list thatincludes the plurality of authentication requests; transmitting, to amobile device of the user, the list that includes the plurality ofauthentication requests; receiving, from the mobile device, a selectionby the user of the authentication request from the list that includesthe plurality of authentication requests that are pending for the user;determining a level of authentication required for the selectedauthentication request, where the level of authentication requiredspecifies authentication information required to successfullyauthenticate the user for the selected authentication request;determining instructions based on the level of authentication required;transmitting the instructions to the mobile device to request theauthentication information from the user; receiving, from the mobiledevice, the authentication information for the selected authenticationrequest; determining a successful authentication, of the user, for theselected authentication request when the authentication informationmatches one or more corresponding values associated with the user;generating an authentication response that indicates the successfulauthentication of the user, for the selected authentication request; andtransmitting the authentication response to the server.
 19. The media ofclaim 18, wherein only non-secret information of the user is exchangedbetween the computer terminal and the server before the authenticationrequest is received from the second server.
 20. The media of claim 18,wherein the authentication request comprises one or more of: anidentifier associated with the user or the mobile device, where themobile device uses the identifier to identify the queue, types ofauthentication information required for the authentication request,where the mobile device uses the types of the authentication informationto prompt the user to provide the authentication information via themobile device, a rule for determining a time when the authenticationrequest expires, where the mobile device uses the rule to determine thetime when the authentication request expires, or the time when theauthentication request expires, where the mobile device removes theauthentication request from the queue when a current time is equal tothe time when the authentication request expires.